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Background of the Invent:ion 
Field of the Invention 

The present invention relates to a Witness system 
that, using EDI (electronic data exchange), supports 
account settlement (accounting) and distribution 
systems among sellers and buyers. 

Description of the Related Art 

Today's distribution systems are manifold and, 
through complex distribution media, carry out the 
distribution of large quantities of goods. As a 
result, accounting processes undertaken between 
sellers and buyers are equally complex. 

The system disclosed in Fig. 1 is representative 
of conventional account settlement ( accounting ) 
systems. First, with each delivery of goods, a buyer 
examines a delivery voucher sent -- or tendered 
contemporaneously on site by a seller. Using, 

illustratively, an internal system in the buying 
company, the buyer then reduces the details to voucher 
form, upon which payment to the seller is to be based. 
This detailed voucher discloses, among other 
information, seller * s name, delivery date, description 



of goods delivered, unit price, quantity, and total 
price. 

The buyer thereafter consolidates and aggregates 
detailed vouchers according, illustratively, to 
payment date, and makes a detailed payment statement. 
The detailed payment statement so made is the result 
of the above-described consolidation and aggregation 
of each detailed voucher. Minute details otherwise 
recorded in a detailed voucher are omitted from the 
detailed payment statement. By way of illustration, 
payment date and total price are reflected in the 
detailed payment statement; more particularized 
details (e.g., delivery date, description of delivered 
items, unit price, and quantity), however, are 
commonly omitted. 

As between a buyer and seller trading daily many 
goods with a payment cycle of one payment per month, 
for example, detailed vouchers corresponding to 
delivered volumes are reduced to a single detailed 
payment statement, and only the aggregated total price 
is established according to the detailed payment 
statement. 

The buyer, using the above described detailed 
payment statement, requests that its bank transfer 
funds in favor of the seller. The bank then makes a 
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deposit for the amount specified in the detailed 
payment statement in favor of the Seller, with respect 
to whom the request for funds transfer was made, 
utilizing, illustratively, an inter-bank exchange 
5 system. As a result, a seller thus receiving payment 
learns, through notification from the bank, the amount 
of money received in the seller's bank account from 
2 the buyer. 

^ The following problems are inherent in a 

10 conventional system like that described above, 
ffl Specifically, the detailed payment statement used in 

. ' the conventional system is a document that compiles 

[T in the aforesaid manner multiple delivery vouchers in 

establishing a total payment amount. A seller is thus 
£^ 15 unable unilaterally to ascertain which delivery 

vouchers are reflected in the total amount paid to it 
by the buyer. This is the result of the omission of 
delivery date, description of delivered goods, unit 
price, quantity, and like information, for discrete 
20 transactions, from the detailed payment statement. 

In such instances, the seller must confirm 
substantive details with the buyer, in order to verify 
the amount of money received. Where, for example, the 
amount of money paid to the seller does not agree with 
25 the total amount invoiced, the seller's accounting 



representative must either confirm with the buyer the 
contents of the detailed vouchers or make discrete 
inquiries regarding payment amounts. This work places 
a significant burden on the accounting departments and 
constitutes a material impediment to enhancing the 
efficiency of account settlement processing. 

Specifically, where a single account settlement 
for a large transaction is undertaken according to the 
detailed payment statement, a great deal of time and 
human effort are required to confirm substantive 
details recorded therein. And, in settling accounts 
with high-volume customers, a seller must undertake 
account settlement in terms of the smallest 
transaction, i.e., by voucher, in order to set 
receivables of f against payables. 

CJh^s^the other hand, with the popularization of the 
internet ,x^he construction of EDI -implemented 
(electronic a^a exchange) information exchange 
systems is being tfe^ed in all functional disciplines. 
It is anticipated tha^bs^se of the system contemplated 
by the present invention wSsJ^, particularly as between 
companies, facilitate more efficient account 
settlement processing and distribution in complex 
distribution channels. 



Summary of the Invention 

.V wcsi-lizing EDI (electronic data exchange), the 

or ^ 

present ihv^ntion provides a Witness system that 
ensures informa^&ton safety, and further provides 
5 " account settlement prb€;^ses making use of said 
Witness system, in order to p&as^^m efficient account 
settlement processing and distribut: 

Specifically, the present invention achieves these 
objectives by providing a Witness system consisting 
10 of: Document making means for making confirmation 
documents based on records prepared by and sent from 
a seller for each seller record; forwarding means for 
forwarding to a notarization authority documentation 
made according to said confirmation document making 
15 means and, further, for forwarding said documentation 
from the aforementioned notarization authority to the 
aforementioned seller; confirmation means for 
confirming whether the content of the aforementioned 
documents forwarded by the aforementioned forwarding 
20 means agree with the content of the aforementioned 
seller records; a Witness for confirming that the 
aforesaid documents are correct, upon establishing the 
aforesaid substantive agreement according to said 
confirmation means; and memory means for storing in 
25 memory documents confirmed by said Witness . 



Records prepared by and sent from a seller 
include, by way of illustration, delivery vouchers, 
written estimates, invoices, and like records. These 
records are used to identify brand names, quantities, 
unit prices, and money amounts, when making details 
concerning goods received by a buyer. "Buyer" and 
"seller" comprise both public and private enterprises. 
The system contemplated by the present invention draws 
no distinction between incorporated and unincorporated 
entities . 

notarization authority (1) receives details 
prepared^^ a seller based, among other things, on 
delivery vouCT^rs, (2) transmits these details to the 
seller, and (3) s^icits from the seller confirmation 
that substantive deW^ils are in agreement with the 
content of the deliv^a;;y vouchers. The Witness 
receives notification tn^ the seller confirms 
substantive agreement, whereupon the Witness certifies 
the aforesaid details as correct documents and 
confirms said details to the afor^^id buyer and 
seller. \^ 

By constructing the system in this way, details 
for discrete deliveries prepared by a buyer are 
confirmed between buyer and seller, as well as by the 
third-party Witness. These details can be used 
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effectively as accurate data in account settlement 
processing. 

Brief Description of the Drawings 

Fig. 1 shows, illustratively, a conventional 
account settlement system. 

Fig. 2 discloses the specific structure of the 
system. 

Fig. 3 discloses the basic structure of the 
preferred embodiment of the Witness system. 

Fig. 4 discloses the structure that stores in 
memory media the programs for the illustrative 
embodiment . 

Fig. 5 discloses the order in which the computer 
performs processes J and K, and L and M, respectively. 
Fig. 6 shows the login screen. 

Fig. 7 shows a screen displaying the start menu. 
Fig. 8 discloses the menu bar details. 
Fig. 9 describes specifically the preferred 
embodiment . 

Fig. 10 presents flowchart describing the 
processes performed by computer 5. 

Fig. 11 presents flowchart describing the 
processes performed by the Witness PC. 

Fig. 12 presents a flowchart describing the 
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processes performed by computer 6 . 

Fig. 13- shows the confirmation data list screen. 

Fig. 14 shows the data confirmation screen. 

Fig. 15 shows the data confirmation screen. 

Fig. 16 shows the confirmed data list screen. 

Fig. 17 shows the confirmed data detail screen. 

Fig. 18 shows the payment list screen display. 

Fig.. 19 shows the payment display screen. 

Fig. 20 discloses a scaled representation of the 
comparison process . 

Fig. 21 describes represents the account 
settlement system in the case of funds transfer. 

Fig. 22 discloses the set-off process flow. 

Fig. 23 presents a flowchart describing the set- 
off process. 

Fig. 24 discloses the basic structure of the 
second alternate embodiment of the Witness system. / 

Fig. 25 describes, with reference to a 
representative display screen, the processes for the 
second alternate embodiment. 

Fig, 26 describes, with reference to a 
representative display screen, the processes for the 
second alternate embodiment. 

Fig. 27 shows the login screen. 

Fig. 28 represents a screen displaying the start 



menu. 

Fig. 29 discloses the menu bar details. 

Fig. 30 shows the company certificate acquisition 
screen. 

5 ' Fig. 31 shows the confirmation number display 
screen. 

Fig. 32 shows the terms display screen, which 

displays the authentication authority terms. 

Fig. 33 shows the certification receipt screen. 

10 Fig. 34 shows the company registration screen. 

Fig. 35 shows the notarization authority terms 
screen. 

Fig. 36 shows the company registration request 
screen. 

15 Fig. 37 shows the company list screen. 

Fig. 38 shows the company detail information 
screen . 

Fig. 39 describes a Witness system utilizing a 
certificate . 

20 Fig. 40 describes specifically the second 
alternate embodiment . 

Fig. 41 describes the data format for encoded 
data. 

Fig. 42 discloses the notarization data list 
25 screen. 
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Fig. 43 discloses the notarization data 
confirmation screen . 

Fig. 44 discloses the notarization data 
confirmation screen. 
5 Fig. 45 discloses the notarized data list screen. 

Fig. 46 discloses the notarized data detail 
screen. 

Fig. 47 discloses the payment list screen display. 
Fig. 48 discloses the payment screen. 
10 Fig. 49 describes the account settlement system in 

the case of funds transfer. 

Fig. 50 discloses examples of other encoded data. 
Fig. 51 describes processing in the case of 
payment by check . 
15 Fig. 52 describes processing in the case of 

payment by draft (note). 

Description of the Preferred Embodiment 

The preferred embodiments of the present invention 
20 are hereunder explained using accompanying figures. 

Fig. 2 discloses the basic structure of the 
Witness system's preferred embodiment. The 
illustrative Witness system consists, fundamentally, 
of: (1) a buying company, as "buyer"; (2) a selling 
25 company, as "seller"; and (3) the Witness, which 
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authenticates, as between buying company 1 and selling 
company 2, delivery vouchers and similar seller 
records. A buying company 1 purchases goods from a 



example, a large supermarket or store, and the selling 
company is, for example, a vendor that delivers goods 
to large supermarkets and like purchasers. The goods 
delivered to the buying company consist, by way of 
illustration, of foodstuffs, articles of clothing, 
daily necessities, and all varieties of commercial 
goods . 

First, buying company 1 sends to the Witness 3 
data that buying company 1 wishes to have confirmed 
by the Witness 3. Exemplary data include that which 
is recorded on a delivery voucher (see Fig. 2(1)). 
Having received this data, the Witness first makes 
record only of the fact that it has received a 
request, and then sends the request, as is, to selling 
company 2 (see Fig. 2(2)). Having received the 
confirmation request, selling company 2 confirms the 
contents recorded in the aforementioned data and then 
executes, with respect to the Witness 3, a 
confirmation response indicating whether selling 
company 2 agrees with said data (see Fig. 2(3)). The 
Witness 3 receives the confirmation response and, if 



selling company 2. 



The buying company is, for 
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selling company 2 agrees with the recorded contents, 
transmits to buying company 1 and selling company 2 
a confirmation response representing that both parties 
have verified the aforementioned data (see Fig. 2(4)). 
5 The Witness 3 is thus possessed of faculties for 

undertaking simple recordation of the fact that it has 
received data from the buying company 1 and for 
proceeding further to confirm data (confirmation 
documents) exchanged between the buying and selling 
10 companies. The Witness 3 manages data and performs 
account settlement (accounting) processes relating, 
for example, to detailed payment statement making and 
funds transfers. 

Fig. 3 discloses the specific structure of this 
15 system. In this figure, diagram 5 represents the 
buying company's computer, and diagram 6 represents 
the selling company's computer (buying company 1 and 
selling company 2 are shown in Fig. 2). The Witness 
PC 9 corresponds to the aforesaid Witness 3. This 
20 Witness PC 9, among other things, confirms delivery 
voucher data output from the buying company's computer 
5, and receives confirmation responses output from the 
selling company's computer 6. 

TiTe"W±tness server 8 comprises: Delivery detail 
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r^a^ting, by way of illustration, to delivery vouchers 
confo^ismed by monitoring system PC 9; payment terms 
table 21^vwhich is described hereinafter; and detail 
group table z^J. The above-mentioned computers 5 and 
6 can access direbtly the monitoring system 8 and can 
refer, illustrativelyX^to the aforesaid confirmation 
documents . 

Additionally, as disclosed in Fig. 4, computer 5 
and computer 6 each perform processes described 
hereinafter according to programs (data) stored, for 
instance, in CPU RAM or on hard disk. The aforesaid 
programs may be supplied from either CD-ROM or floppy 
disk, or, alternatively, from a program (data) 
^provider by means of a circuit. 

>y disclosed in Fig. 3, the buying company's 

computerSs^xecutes requests for confirmation (process 
J) and executes administrative processing (process K). 
The aforesaid pro^sses are performed using database 
5a and library datab^^ 5b (in computer 5). Library 
interface 5 is used in^^is case. Similarly, the 
selling company's compurfer 6 executes data 
confirmation requests (process I>). and administrative 
processing (process M). These procesfeses are performed 
using database 6a (in computer 6) and li0X;ary database 
6b, via library interface 6c. The dotted pbrtions in 
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F*ig . S^-ii^present; a corporate client; library, which 
functions, bywa5^-efillus-tration, as an interface for 
connecting to a networK>^ 

The specification next describes processing in a 
Witness system constructed as described above. 

Fig. 5 discloses the order of processing when 
computer 5 executes processes J and K, or, 
alternatively, when computer 6 performs processes L 
and M. The display screen transition also is shown 
in Fig. 5. 

To begin processing for buying company 1, the user 
powers up computer 5, enters network user name and 
password, displays the icon corresponding to this 
system by, for example, clicking the [OK] indication 
on the screen, and double-clicks said icon to start 
the system. The same procedure is followed to start 
the selling company's computer 6, as well as the 
Witness PC 9 . 

The above-described process causes a login screen, 
as represented in Fig. 6, to appear on the display of 
computer 5 (and on that of computer 6). This login 
menu is used to start the Witness system disclosed in 
the illustrative embodiment and corresponds to the 
start screen in Fig . 5 . 

By entering a user I.D. and network password and 



# 
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activating the login button from this screen, computer 
5 (computer 6), for example, checks the user I.D. and 
password and, if they match, shifts to menu display 
to display the menu screen. If the cancel button is 
5 pressed, the display returns to the previous OS start 
screen. 

Fig. 7 shows the start menu displayed in response 
to manipulation of the aforesaid login button. Said 
03 start screen consists of four buttons (display), 27a- 

'^Z . 10 27d, and a menu bar. As Fig. 8 discloses, the menu 

'f^^ bar includes a quit bar. 

s First, each button on the start menu is explained. 

M: Button 27a is used when directing the system to 

ni perform a confirmation request. Button 27b is used 

15 when directing the system to perform a payment list 
inquiry. Button 27c is used to direct the system to 
look at confirmed data. Button 27d is used to close 
the program described in the illustrative embodiment. 
Each button is activated, for example, by manipulating 
20 a mouse so as to position the cursor at any one of the 
buttons 27a-27d, and then double-clicking the mouse 
button. 

As disclosed above, among the processes that buyer 
company's computer 5 performs are processes J and K, 
25 and among those performed by selling . company's 
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computer 6 are processes L and These processes are 
specifically explained below. 
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Confirmation Request Process (Process J): 

This process is performed by buying company 1 and 
is carried out based on either a delivery voucher, 
order voucher, or invoice, any of which serves as a 
r seller record. Specifically, the buying company 1 
^ produces confirmation documents based on a voucher 
sent to it by selling company 2 and then sends the 
V documents to the monitor. 

Fig. 9 specifically describes this process. Fig. 
10 presents a flowchart explaining the processes 
performed by computer 5. Each time buying company 1 
receives goods from selling company 2, the data 
contained in the delivery voucher that buying company 
1 receives is output from computer 5 to the Witness 
PC 9. 

Fig. 9 illustrates, store A, the selling 
company 2,^"^d^livers to supermarket B, the buying 
company 1, certain>§qods tuffs and, at that time, sends 
to supermarket B S'^^^ delivery voucher (or, 
alternatively, tenders the voltslier with the goods) 
Computer 5 waits for input of the "Shivery voucher 
(step 1, hereinafter "SI", is N (no)), ami>^ when the 
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^livery voucher is entered (SI is Y (yes)), the 
sy&tem performs input processing of the voucher 
information. As the example presented in Fig. 9 
shows \ buyer company 1 ( supermarket B ) produces the 
aforesa\d delivery voucher data as confirmation 
documental. Included in this confirmation document 
XI are, i\lustratively, deliverer's name (selling 
company 1), delivery date, description of delivered 
goods, and delivered price. The following information 
is xllustrativex of that which is reflected in the 
confirmation docT^ent: The aforesaid deliverer is 
store A; the deliv^y date is February 10, 1998; the 
delivered goods consist of tuna; and the delivered 
price is 1,5000 yen. ^This confirmation document XI 
is transmitted (S3) frOm buyer company 1 to the 
Witness 3 (see Fig. 9 ( 1 ) ) . \Buying company's computer 
5 thereafter waits for a response with respect to the 
aforesaid transmitted data (S4)V 

12 presents a flowchart describing the 
processes peiikjrmed by selling company's computer 6. 
The Witness PC 9 wa:t*t^ for the data input from the 
aforesaid computer 5 (S5 i^"^"^ (no)), and, when the 
input is available (S5 is Y (y^s^), confirms the 
content of the input data (S6) ancv^jjhere, for 
example, the data supplied to the monito^v^PC 9 
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^■^Qrrespond to the above described confirmation 
document"'"""''Xi>.,..^^said confirmation document XI is 
registered in detaiit^biQ20, described above (S7) 
(see Fig. 9(2)). Confirmation docurTTefvt-.^Xlis then 
output, as is, to selling company's computer 6 (S§>>^ 
Data Confirmation Process (Process K) 

F\g. 12 is a flowchart describing the process that 
selling company's computer 6 performs. As described 
above, Computer 6 waits for the confirmation document 
XI input \sent from the Witness PC 9 (S9 is N (no)), 
and, when csonf irmation document XI is input (S9 is Y 
(yes)), compares confirmation document XI with the 
contents of thp delivery voucher that it previously 
sent (or tendei^ed with delivery) (SIO). It also 
checks to for the\)resence of errors in the contents 
of the delivery voNicher. As noted above, it is 
selling company 2 thaH; performs this error-checking 
task. A "buying company" with whom selling company 
2 places its goods is, however, not strictly limited 
to a specific company ( the\ aforesaid buying company 
1). Accordingly, when undertaicing the above-described 
error-checking task, selling \:ompany 2 presses the 
confirmation request button on N$:he computer 6 start 
menu (see Fig. 7) and displays trf^ confirmation data 
list screen shown in Fig. 13. 
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Fig. 13 is illustrative of the result following 
manipulation of retrieve button 40a, located on the 
confirmation data sight screen, and subsequent 
selection of "supermarket B" . To confirm this 
5 certification, selling company 2 presses detail button 
40b and displays the detail screen. Pressing the quit 
button 40c restores the above-described start menu. 

Here, the aforesaid detail button 40b is pressed, 
and the detail screen depicted in Fig. 14 appears. 
10 While looking at this screen, selling company 2 
compares the content of the confirmation document XI 
sent by the monitor 3 with the content of the delivery 
voucher, or similar document, issued by selling 
company 2 (SIO). Selling company 2 then determines 
15 whether there are any errors (Sll). Here, if both 
documents are in substantive agreement, selling 
company 2 presses confirmation button 41a. The 
confirmation data is then produced and transmitted to 
the Witness PC 9 (Sll is Y (yes), S12, and S13) (see 
,Fig. 9(4)). 

rf7--..Qn the other hand, it is determined that the 
aforesaid deliv^ty-^ioucher , or similar document, and 
the confirmation documentlt3r-d4ff er substantively (Sll 
is N (no)), selling company 2 press^^&^j^ button 41b, 
25 shown in Fig. 14, and produces the display-^L^closed 
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irr---fet*e*^aame figure. Specifically, selling company 2 
in this case descrTB'&9-4::Jiereason for -fche NG condition 
(S14), presses OK button 41, sho^^Tnr-^iixFig . 14, and 
sends a NG response to the Witness PC 9 (SlB>%. 

When this NG response is available (S5 in Fig. 11, 
is Y (yes)), the Witness PC 9 judges the contents of 
the input data (S6) and, in the case of a NG response, 
sends this information, as is, to buying company's 
computer 5 (S16). The Witness system thereafter waits 
for correction data input (S17). Buying company's 
computer 5 thus waits for the receipt of data (S4) 
and, in the case of a NG response when the response 
data is input (S18, see Fig. 10, is Y (yes)), 
undertakes correction corresponding to confirmation 
document XI (S19). The corrected data is sent a 
second time to the Witness PC 9 (S20), and receipt 
detail table 20 of the Witness PC 9 is corrected (S17 
is Y (yes), S21 ) . Specifically, selling company 2 is 
able to: learn of an error or errors in the details 
generated by buying company 1; notify buying company 
1 of the error or errors; and (3) by, for example, 
correcting the content of the details, update the 
contents of receipt detail table 20, thereby enabling 
the of accurate details (see Fig. 9(5)). 

The process described above is performed each time 



a delivery voucher is sent between buying company 1 
and selling company 2, and several authentication 
documents are registered in the delivery receipt 
detail table 20 shown in Fig. 9. If, as represented 
in Fig, 9, the delivering company is store A, the 
delivery date is February 11, 1998, the item delivered 
is saury, and the delivered price is 10,000 yen, a 
confirmation document X2, for example, is registered 
in the delivery detail table 20 according to the same 
process. 

Where selling company 2 determines that there are 
no substantive errors as between its delivery voucher 
and the confirmation document XI, and selling company 
2 sends a confirmation response to the Witness PC 9, 
the Witness PC 9 confirms the content of the input 
data (S5 and S6, shown in Fig. 11), and the Witness 
PC 9 notifies buying company 1 and selling company 2 
that the data has been confirmed by both parties (S22) 
Specifically, when the Witness 3 has a "confirmation 
complete^''*^v4^put from selling company 2, it transmits 
to buying corttjiany 1 and selling company 2 
verif ication-completeS'^vqonf irmation documents A and 
B, relating, for example /''''^"'feo the above-mentioned 
confirmation documents XI and X2 ( se&se^a . 9(6)). The 
information thus transmitted from the Wittiess 3 is 
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cisinf irmed by both buying company 1 and selling company 
2 ana^e^es to verify that there is no substantive 
error in a ctsinf irmation document based, for example, 
on a delivery voboher. 

When the confirmation process is completed as 
described above, confirmation documents based on 
several delivery vouchers are registered in the 
receipt detail table 20. 

Tto refer in this state to data that have been 
confirmed and registered in the receipt detail table 
20, the ueer presses the confirmed data list button 
7c, therebyS^hif ting the display from the start menu 
conf igurationNfco the confirmed data screen represented 
in Fig. 16. Thre confirmed data list screen enables 
the user to selec^ from among several customers, a 
customer with which t^e user has current transactions, 
such as, by way of illustration. "OO Foods Company", 
"XX Ham Company", or "ABC^ompany" . The user can also 
specify and select items in cJ-assif ication areas, such 
as "wholesale", "set-off"/S. "orders", "accounts 
receivable", "payment correcticn^s" , and "contracts". 
Pushing button 45a, moreover, displays the confirmed 
data detail screen, shown in Fig. 17\ 

Fig. 17 discloses the detail screen that appears 
when, by way of illustration, "orders" is selected as 
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the aforesaid classification item. As is shown in 
that figure, detailed information relating to the 
selected classification item is displayed, and the 
user is able to review in detail such specific 
authentication information as item name, quantity 
"10", unit cost "100 yen", and total cost "1000 yen". 
Office Administration Processing (Processes L and M) 

The specification next explains office 
administration processing. Office administration 
processing (process L) includes payment corrections, 
payment detail display, and like varieties of 
administrative processing. The payment correction 
process involves the correction of price or 
description of goods, pursuant to an indication of 
discrepancy made by selling company 2. Price 
establishment processes comprise, illustratively, 
responsive processes that are performed by confirming 
a detailed payment statement made by the Witness 3, 
and processes for outputting detailed payment 
statements that buying company 1 itself has made. 
These processes are specifically explained below. 

Fig. 18 represents a payment list screen 
appearing, for example, on computer 5. This payment 
list screen can be displayed by pushing the payment 
list inquiry (reference) button 27b, thus bringing 
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about a transition from the start menu configuration 
shown in Fig. 7, This payment list screen is 
generated by the Witness 3, By selecting payor, one 
is able to -select from among several possibilities a 
5 company with which the user has current transactions 
(e.g., "00 Foods Company", "XX Ham Company", or "ABC 
^ Company"). Similarly, a payee can be specified, and, 

fl by specifying a date certain, a payment list screen 

35 showing that date as the due date is displayed. 

"5 10 Displayed on this detailed list screen are the 

"^i delivery date recorded on the payment voucher, voucher 

number, store name, wholesale price, and discount 
=^ rate. An operator can specify another payment voucher 

Jj about which information is desired, and, by pressing 

y 15 detail button 44a, can shift to the detail screen 

shown in Fig. 19. 

The illustration in Fig. 19 represents a payment 
voucher issued against "00 Foods Company", pursuant 
to which payment to "ABC Company" is due no later than 
20 August 12, 1997. When an operator at either buying 
company 1 or selling company 2 displays this 
information, the system investigates the product name, 
unit weight, quantity, unit price, and total price, 
and, in case of doubt, checks each detail registered 
25 in the above-mentioned receipt detail table 20. If, 



for example, the total amount is different from the 
total amount based on the delivery voucher in the 
operator's possession, each detail registered in the 
receipt detail table 20 is confirmed. 

In this case, the system would refer to registered 
confirmation data residing in the receipts detail 
table 20. Specifically, by pushing the confirmed data 
button 7c from the start menu shown in Fig. 7, the 
aforesaid list screen, shown in Fig. 16, is displayed. 
It is also possible to cross-check payment data by 
displaying the confirmed data detail screen. 

Making of the detailed payment statement is 
undertaken, for example, by the Witness 3, and 
completed by referring to the payment terms table 21. 
According to prior arrangement between buying company 
1 and the Witness 3, or between selling company 2 and 
the Witness 3, information such as closing date, 
payment date, and deposit account number are for each 
company registered in the payment terms table. 
Additionally, each detail is numbered, and, to make 
data checking more convenient for buying company 1 and 
selling company 2, a detail group table 22, which 
groups the detail numbers, is provided. 

Fig. 20 presents a scaled drawing of the cross- 
checking process described above. Selling company 2 




26 

perforins cross-checking of detailed information with 
the Witness 3 (see Fig. 20(1)) and, referring to 
either the receipts detail table 20 or the payment 
terms table 21, obtains the necessary detailed 
5 information (see Fig. 20(2)). On the other hand,^ 
buying company 1, also, performs cross-checking of 
detailed information with the Witness 3 (see Fig. 20 
lQ ( 3 ) ) , as required, and, referring to either the 

receipts detail table 20 or the payment terms table 

-i: 10 21, obtains the necessary detailed information (see 

yi 

W Fig. 20(4)). 

= Next, the Witness 3 specifies the deposit account 

L,^ of the accounting department (i.e., a designated bank) 

f!'; and makes a request for deposit, based on the 

^ 15 aforesaid detailed payment statement (see Fig. 9(7)). 

Here, using Fig. 21, the specification explains the 
deposit and cross-checking processes. 

Documents authenticated in the above-described 
manner are registered in the Witness server 8. First, 
20 the Witness 3 makes the detailed payment statement 
based on data registered in the receipts detail table 
20 and then requests confirmation from buying company 
1 (see Fig. 21(1)). Buying company 1 confirms the 
detailed payment statement sent to it and returns the 
25 statement as its request for funds transfer (see Fig. 
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21(2)), At this time, a delivery voucher index 
corresponding to the detailed payment statement is 
assigned to said statement. 

The aforesaid funds transfer request is delivered 
5 to the Witness 3 and forwarded to a bank (not shown 
in the instant drawing) (see Fig. 21 (3)). The 
information that the Witness 3 sends to the bank as 
the Witness' instruction for funds transfer comprises 
the money amount, transferor, transferee, and the 

10 detail index. Having been so instructed to transfer 
funds, the bank transfers funds to selling company's 
transaction bank, utilizing a suitable banking system, 
such as an inter-bank transfer system. The paying 
bank notifies selling company 2 of payment (see Fig. 

15 21(4)). 

By undertaking processing as described above, 
neither buying company 1 nor selling company 2 is 
required to hold several vouchers or invoices. 
Additionally, it is possible to perform efficient 

20 account settlement using data shared with the Witness 
server 9 , 

First Alternate Embodiment: 

The specification next describes the first 
alternate embodiment of the present invention. If 
25 buying company 1 and selling company 2 were to change 
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places, processing efficiency would be impaired if 
respective detailed payment: statements were made in 
the same manner as that contemplated in the preferred 
embodiment. This illustrative embodiment performs 
set-off processing and makes a detailed payment 
statement ( suitable to the aforesaid contingency ) . 

Accordingly, the system structure disclosed in 
Figs. 2 through 4, as well as the illustrative screen 
progression shown in Fig. 5, are the same as those in 
the preferred embodiment. The making of confirmation 
document X based on delivery vouchers from selling 
company 2 is the same as that undertaken in the 
preferred embodiment. The confirmation process at 
selling company 2, as well as the authentication 
processes performed by the Witness 3 are the same. 
A plurality of authenticated data are registered in 
the detail receipts table 20 of the Witness server 8, 
and the Witness 3 makes detailed payment statements 
matched to payment dates in the payment terms table 
21. 

Fig. 22 discloses the set-off process flow for the 
illustrative embodiment. Fig. 23 is a set-off process 
flowchart. The illustrative embodiment performs set- 
off where, according to the relationship between the 
aforesaid buying company 1 and selling company 2, 
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buying company 1 bears a payment: obligation with 
respect to selling company 2, and, at the same time, 
selling company 2 bears a payment obligation because, 
for example, it has purchased distinct goods from 
5 buying company 1. In this case, the system extracts 
all details relevant to buying company 1 and buying 
company 2 registered in delivery detail table 20 
p "vendor" and "buyer" columns (Step 1, hereinafter "ST" 

03 in Fig. 23). Respective payment amounts are displayed 

yi 10 (ST2), the money amount where buying company 1 is the 

t'l buyer and selling company 2 is the vendor is added 

f (+), the money amount where selling company 2 is the 

N= buyer and buying company 1 is the vendor is subtracted 

y (-), and the set-off amount is calculated (ST3). 

J! 15 The payment amount relating to mutual trade 

between buying company 1 and selling company 2 is thus 
set-off according to the above calculation, and, in 
the preceding illustration, if the total money amount 
carries a positive (+) value, buying company 1 pays 
20 to selling company 2 the resultant money amount (ST4 
is Y (yes), ST5 ) . If, on the other hand, the total 
money amount carries a negative (-) value, selling 
company 2 pays to buying company 1 the resultant total 
money amount (ST4 is N (no), ST6). 
25 The money amount thus derived is reduced to a 
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detailed payment statement, and, as described above, 
the Witness 3 specifies the accounting department 
(i.e., a designated bank) receiving account and 
executes a funds transfer request based on the 
5 aforesaid detailed payment statement (see Fig. 22 
(1)). By performing processing as described above, 
it is possible to reduce the number of detailed 

iij payment statements and to make detailed payment 

03 statements with greater efficiency. 

10 Set-off for payment amounts as between buying 

company 1 and selling company 2 is not limited to the 

3 foregoing illustrative embodiment, but is amenable to 

other methods as well . 

r1 Second Alternate Embodiment 

^ 15 The specification next describes the second 

alternate embodiment of the present invention. 

The second alternate embodiment is an invention 
for safely performing account settlement in an account 
settlement system utilizing the Witness. This 

20 illustrative embodiment performs processing in 
accordance with authentication numbers after 
authenticating buying company 1 and selling company 
2 in advance. Furthermore, the illustrative 

embodiment encodes data sent and received between 

25 buying company 1 and the Witness, or, alternatively. 
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between selling company 2 and the Witness, and ensures 
the protection of data. This illustrative embodiment 
is explained below. 

Fig. 24 discloses the specific structure of this 
system. In this figure, 5 represents the computer of 
buying company 1, which is the same as that in the 
preceding illustrative embodiments, and 6 represents 
the computer of selling company 2. The notarization 
authority 7 and the Witness server 8 correspond to the 
aforesaid Witness 3 and are included in the Witness 
PC 9. The Witness PC 9 includes an authentication 
authority 24, which authenticates in advance the 
companies that participate in this system. 
Additionally, the Witness PC 9 in this illustrative 
embodiment notarizes (certifies) delivery voucher and 
like data output from buying company's computer 5, and 
also receives confirmation responses output from 
selling company ' s computer 6 . 

The Witness server 8 consists, among other things, 
of: detailed receipts table 20, which stores 
notarization documents, illustratively comprising 
delivery receipts notarized by the Witness PC 9; 
payment terms table 21; and detailed group table 22. 
The aforesaid computer 5 and computer 6 can access 
directly the Witness server 8, to refer to the above- 
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mentioned notarization documents and like documents. 

As disclosed in Fig. 24, buying company's computer 
5 performs company certificate acquisition (process 
A), company registration processing (process B), 
5 notarization request processing (process C), and 
office administration processing (process D). Selling 
company's computer 6, on the other hand, performs 
company certificate acquisition (process E), company 
registration processing (process F), notarization data 

10 confirmation processing (process G), and office 
administration processing (process H). 

The authentication authority 24 executes 
authentication of certification requests issued in 
regard to the corporate certificate acquisition 

15 processes (viz,, process A and E) undertaken by buying 
company ' s and selling company ' s computers ( computer 
5 and computer 6, respectively). Similarly, the 
notarization authority 7 performs notarization of 
certificate issue registration requests issued in 

20 regard to company registration processing (viz., 
process B and F) carried out by buying company's and 
selling company's computers (computers 5 and 6, 
respectively) . 

Figs. 25 and 26 describe, in parallel with the 

25 representative screens that would appear on the 
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display, the processes of this illustrative 
embodiment. A specific explanation follows. 

In this illustrative embodiment, computers 5 and 
6 and the Witness PC 9 are powered up, and the Witness 
system program is started. 

Through this process, a login screen, represented 
in Fig. 27, appears on the computer 5 (or computer 6, 
for that matter) display. This login screen is used 
to open the monitor system in this illustrative 
embodiment and corresponds to the start screen in Fig. 
25. As with the previously described embodiments, 
entering a user I.D. and password and pressing the 
login button in the login screen causes computer 5, 
for example, to confirm the user I.D. and password. 
If the user I.D. and password are in agreement, the 
system transitions to menu display and brings up the 
menu screen. Pressing the cancel button returns the 
system to the previous, initial operating system 
screen. 

Fig. 28 represents the initial menu screen 
displayed when the login button is pressed. The 
initial menu comprises four buttons (display), 10a 
through lOd, and menu bar 11. Fig. 29 discloses 
details of the menu bar 11. Button 10a is pressed to 
instruct the system to confirm notarization requests. 
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But:t:on 10b is pressed to instruct the system to 
retrieve a payment list. Button 10c is pressed to 
instruct the system to list notarized data. Button 
lOd is pressed to quit the program in this 
5 illustrative embodiment. 

As shown in Fig. 28, The menu bar 11 consists of 
quit bar 11a, company registration lib (company 
certificate acquisition bar lib' , company registration 
bar lib"), company information bar 11c, environment 
10 settings bar lid, and version information bar lie. 

The alphabetic characters (X, E, I, S, A) assigned 
respectively to each of the bars are used when 
designations (specifications) are made via the 
keyboard . 

15 As described above, buying company's computer 5 

performs processes A through D, and selling company's 
computer 6 performs processes E through H. These 
processes are described specifically below. 

Company Certificate Acquisition Processes 

20 (processes A through E) 

These are processes for admission to the system 
and must be performed initially when, for example, 
this system is adopted. Designation of these 
processes is accomplished by selecting the company 

25 certificate acquisition bar in the menu screen shown 
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in Fig. 29 (Fig. 28) and displaying the company 
certificate acquisition screen shown in Fig. 30. As 
described above, the company certificate acquisition 
process (process A) is a process for registering 
5 companies participating in the Witness system in the 
illustrative embodiment and designating company 
registration numbers for companies whose company 
certificates are to be acquired, URL for the 
authentication authority, server name, and the type 

10 of certificate. 

Next, if there are no problems with respect to the 
entered company registration I.D., authentication 
authority's URL, or server name, the certificate 
request button 12a is pressed, producing the 

15 confirmation number display screen. When the quit 
button 12b is pressed, the display restores the 
initial menu shown in Fig. 28. 

Fig. 31 discloses the confirmation number display 
screen. After confirming the displayed number, the 

20 operator presses the "next" button 13a and displays 
the authentication authority terms. In this case, 
too, pressing the cancel button 13b restores the 
company certificate acquisition screen shown in Fig. 
30. 

25 Fig. 32 discloses the provisions display screen. 
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indicating the certification authority terms. Among 
these terms are, illustratively, regulations 
pertaining to admission to this system. The operator 
reads the terms and, if the operator agrees therewith, 
presses the consent button 14, or, conversely, if the 
operator is unable to agree, presses the cancel button 
14b. When the acceptance button 14a is pressed, the 
display shifts to the next certificate acquisition 
screen. 

Fig. 33 discloses the certificate acquisition 
screen. Company name, address, and other information 
relating to company in question are recorded in the 
corresponding areas therein, and the application 
request is made. After confirming that there are no 
mistakes in each of the entries, the application 
request is executed by pressing the application 
request button 15a. The aforesaid authentication 
authority registers the company pursuant to this 
request . 

Company Registration Processing (processes B and F) 
Company registration processing is performed after 

company certificate acquisition processing is 

completed as described above. 

Fig. 34 discloses the company registration screen, 

which can be displayed by pressing the company 
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registration bar lib" in the start menu. This company 
registration process registers participating companies 
with the notarization authority 7 and designates the 
notarization authority 7 URL, server name, and the 
5 monitor I,D. (it is permissible, moreover, to 
abbreviate the server name and the monitor I,D,)- 
This process also designates company registration I.D. 
for participating companies. 

Next, if there is no problem with, illustratively, 

10 the designated company registration I.D,, the 
notarization authority 7 URL, and server name, 
registration number button 16a is pushed, producing 
the terms screen for the notarization authority 7. 
Pressing the quit button 16b restores the start menu 

15 screen. 

Fig. 35 discloses the notarization authority terms 
screen. This screen, like that for the certification 
authority terms, presents, by way of illustration, 
regulations respecting admission to the system, 

20 confirmation items, and like entries. The operator 
read these terms and, if the operator agrees 
therewith, presses the consent button 17a, or 
conversely, if the operator is unable to agree, 
presses the cancel button 17b. When the consent 

25 button 17a is pressed, the display shifts to the next 
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company registration request screen. 

Fig. 36 discloses the company registration request 

screen, through which, company name, address, and 

other information relating to the company in question 
5 are recorded and the application request is executed. 

After confirming that there are no errors in each of 
_ the aforesaid entries, the request is executed by 

u3 pressing the application request button 18a (the 

03 cancel button 18b is pressed to terminate the request 

m 10 process). 

^ The notarization authority 7 registers companies 

with the Witness server, pursuant to the above- 
M described process. 

iTi Company List Display 

ti' 15 Once each company has, as described above, 

executed registration with the notarization authority 
7 and the authentication authority 8, registration 
data for a plurality of companies are registered in 
the Witness server 9. Then, pursuant to user 

20 designations, the system is capable of displaying a 
list of registered companies. 

This company list is displayed by pressing the 
company information bar 11c from the start menu. Fig. 
37 discloses the registered company list display 

25 screen, on which is displayed registered company I.D., 
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company name, and registration date. In this 

illustration, company name "OO Foods Company" has been 
registered in area 1, company name "XX Ham Company" 
in area 2, and "ABC Company" in area 3. If there 
5 exists a company that a user wishes to examine in 
greater detail, the user specifies the company name 
and presses the detail button 19a, after displaying 
'f^ the above-described screen. 

ffl Fig. 38 discloses the company detailed information 

m 10 screen that is displayed by pressing detail button 19. 

n This display consists of company I.D., company name, 

:^ address, signature certification information, and 

H= encoding certificate information. If, for example, 

y the company name "ABC Company" registered in area 3 

5? 15 (se Fig. 28) is selected, the I.D. for "ABC Company" 

is registered in the company I.D. area, and the 
address for "ABC Company" is registered in the address 
area. Information to be registered with the "ABC 
Company" notarization authority is displayed in the 
20 signature certification information area, and the user 
can observe, for example, that certificate number 20 
was issued on November 9, 1997, and that a 
registration valid through May 10, 1998 has been 
executed . 

25 When the authentication process for companies 
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participating in the system (e.g., buying company 1 
and selling company 2) is completed, an encoding 
process is next performed. 

5 Notarization Request Process (Process C) 

This is a process performed by buying company 1 
and is carried out based on such seller records as a 
delivery voucher, an order voucher, or an invoice. 
Specifically, it is a process wherein buying company 

10 1 makes notarization documents, based on any one of 
the vouchers sent to it by selling company 2, and 
seeks notarization from the Witness 3. 

It is Fig. 39 that specifically describes this 
process . Fig . 39 is a scaled representation of the 

15 authentication process, which is executed by attaching 
the above-described certificate received by buying 
company 1 and selling company 2. Buying company . 1 
appends to the authentication document the certificate 
[A] for buying company 1 and sends these documents to 

20 the Witness 3 (process (1) in Fig. 39). The Witness 
3 sends the authentication documents thus received, 
as is, to selling company 2 for confirmation (process 
(2) in Fig. 39). Selling company 2 checks the 
documents sent to it and, after confirming, 

25 illustratively, that the documents are in agreement 



with the content of a delivery voucher, attaches its 
certificate [B] and sends the documents to the Witness 
3 (process (3) in Fig. 39), In addition to 

registering the authentication document data in the 
receipts detail table 20, the Witness 3 sends to both 
buying company 2 and selling company 1 notification 
that the Monitor has authenticated the authentication 
documents (process (3) in Fig. 39). This process is 
executed by appending the Witness' 3 certificate [C] . 
By thus appending the certificate to each document 
forwarded, the notarization authority 7 (Witness 3) 
is at once able to confirm at all times that the 
documents are those of companies eligible to 
participate in the system and to execute safe 
procedures . 

Fig. 40 is used to advance a specific explanation. 

First, store A delivers foodstuffs to supermarket 
B, the buying company, and contemporaneously sends (or 
tenders on site) a delivery voucher. Selling company 
1 (supermarket B in this example) prepares data for 
use as a notarization document Y. Included in the 
notarization document Y are the deliverer's name 
(selling company 2 in this example), delivery, date, 
description of delivered goods, and delivery price. 
Illustrative entries are as follows: deliverer's 
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name/ "store A"; delivery date/ "February 10, 1998"; 
description of delivered goods/ "tuna" ; delivery 
price/"15, 000 yen". The notarization document Y is 
transmitted from buying company 1 to the Witness 3 
(see Fig. 40(1)). The notarization document Y sent 
from buying company 1 to selling company 2 is first 
encoded . 

Fig. 41 is representative of this process. Here, 
a notarization document Y is sent from company U to 
company V. Adapting this scenario to the above 
illustration, the portion shown as "a" in the figure 
corresponds to a message relating to the sending of 
notarization document Y from buying company 1 to 
selling company 2. Specifically, DATA shown in Fig. 
41 corresponds, illustratively, to the deliverer's 
name and delivery date data, mentioned above. These 
data are encoded by means of DES, a hash function 
(SHA) is applied, further . secured with buying 
company ' s secrecy key ( SKA ) , and sent to the 
notarization authority 7. A pubic access key (PKA) 
for the (SKA) is also sent with the data. The data 
are secured with buying company's secrecy key (SKA) 
to enable confirmation at selling company 2 that the 
message has been sent. 

The totality of transmission data sent from 
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company U to company V is secured by locking with 
company U's secrecy key (SKU) a (message) to which a 
hash function (SHA) has been applied. This is further 
locked by DEK, which, in turn, is further secured by 
5 locking DEK corresponding to DES with company V * s 
public access key (PVK). Locking with company V's 
public access key (PKV) ensures that the body of 
transmission data is susceptible of deciphering by 

hi company V only. Specifically, the body of 

10 transmission data is sent from buying company 1 to 

^f'i selling company 2. 

= Notarized Data Confirmation Process (Process G) 

M Next, the Witness 3 sends the aforesaid 

notarization document Y to selling company 2, the 
rf 15 sender of the delivery voucher, and executes a 

confirmation request (see Fig, 40(3)). Selling 
company 2 compares the content of the notarization 
document *Y transmitted from the Witness 3 with, 
illustratively, the content of a delivery voucher that 
20 selling company 2 itself issued, checking for errors. 

The above-described data is unlocked by means of the 
aforesaid public access key. 

Selling company 2, which has received the totality 
of transmission data, first unlocks the data with the 
25 secrecy key (SKV) corresponding to the public access 
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key (PKA), obtains the DEK, unlocks the DES by means 
of the DEK, and then, as described above, utilizes 
buying company's public access key. 

The confirmation task is, as above explained, 
5 performed by selling company 2. A buying company to 
which selling company 2 delivers goods is, however, 
not limited to the company prescribed above (buying 
u3 company 1), Accordingly, when performing the 

m aforesaid confirmation task, selling company 2 presses 

-I— 

m 10 the notarization request confirmation button 10a in 

^ the computer 6 start menu (see Fig. 28), thereby 

- displaying the notarized data list screen, disclosed 

in Fig, 42. 

hj Fig. 42 illustrates a scenario wherein 

'ti 15 "supermarket B" is selected by manipulating the search 

button 20a on the notarized data list screen. To 
confirm this certificate, selling company 2 presses 
detail button 20b, thereby displaying a detail screen. 
When the detail button 20b is thus pressed and the 
20 detail screen displayed, the detail screen depicted 
in Fig. 42 appears. While observing this screen, 
selling company 2 confirms the content of the 
notarization document Yl, transmitted to it from the 
monitor 3, with the content of, illustratively, a 
25 delivery voucher that selling company 2 itself issued. 
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checking for errors. If the contents are in 
agreement, OK button 21a is pressed, and a completion 
(message) is transmitted to the Witness 3 (see Fig, 
40(4)), 

The confirmation response sent by selling company 
2 to the Witness 3 corresponds to that which is 
designated "b" in Fig. 41, Specifically, the encoded 
data for the aforesaid notarization document Yl is 
secured by means of a hash function (SHA) and selling 
company ' s secrecy key ( SKB ) , and then sent to the 
notarization authority 7. A public access key (PKB) 
corresponding to the secrecy key is sent 
simultaneously to the notarization authority 7. 

If it is determined that the content of the 
notarization document Yl is not in accord with, 
illustratively, the content of a delivery voucher, 
confirmation NG button 21b shown in Fig. 43 is 
pressed, resulting in the display represented in the 
same figure. Specifically, the operator describes the 
reason the reason for NG and presses OK button 22a. 
In this case, the Witness 3 notarizes no details, and, 
at this point. Seller 2 learns that there is an error, 
or that there are errors, in the details prepared by 
Buyer 1. Seller 2 notifies Buyer 1, and, as the 
content of the details are revised, the receipts 
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detail table 20, for example, is updated, thereby 
enabling Buyer 1 to produce accurate notarization 
details (see Fig. 40(5)). 

Once the Witness 3 has a confirmation response 
5 from selling company 2, it transmits to selling 
company 2 and buying company 2 a confirmed certificate 
relating to the notarization document Yl (see Fig. 
9(6)), 

The certificate that selling company 2 sends at 

10 this time to the Witness 3 corresponds to that which 
is designated as "c" in Fig. 41. Specifically, it is 
a message secured by means of ( 1 ) a hash function 
(SHA) applied to encoded data relating to notarization 
document Yl and (2) the monitor's 3 secrecy key (SKN). 

15 An access key corresponding to said secrecy key (SKN) 
is at this time sent to both buying company 1 and 
selling company 2. 

Thus, decoded information sent from the Witness 3 
constitutes a certificate that has been confirmed 

20 mutually by buying company 1 and selling company 2, 
and further constitutes a notarization document 
certifying that there are no substantive errors in the 
authentication document based, illustratively, on a 
delivery voucher. As the notarization process is thus 

25 completed, a plurality of certificates are registered 
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in the receipts detail table 20. 

System users can consult notarized, registered 
data residing in the receipts detail table 20 by 
pressing start menu (see Fig. 28) button 10c, which 
5 enables viewing of the notarized data list. The 
resulting notarized data list screen is disclosed in 
Fig. 45. The notarized data list screen allows the 
dl user, for example, to select "customer" and then 

gj specifically identify, illustratively, "00 Foods 

yJ 10 Company", "XX Ham Company", "ABC Company", or any 

buying company 1 with which the selling company 
^ currently has transactions. The user can also select 

1-^ matters that the user wishes to confirm by specifying 

Q items in the classification areas "wholesale", "set- 

15 off", "orders", "accounts receivable", "payment 
corrections", and "contracts". Pressing detail button 
25 displays the notarized data detail screen shown in 
Fig. 46, 

Fig. 46 represents the detail screen displayed 
20 when the classification item "orders" is selected. 

As shown in Fig. 46, detailed information for the 
selected item is displayed, facilitating review of 
specific authentication details including, 
illustratively, product name, quantity ("10 pieces" 
25 in this example), unit price ("100 yen" in this 
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example), and total price ("1000 yen" in this 
example ) . 

Office Administrations Processes (Processes D and 

H) 

Next, the specification describes the office 
administration processes. Among the office 

administration processes (process D) are payment 
correction, payment detail display, and various 
varieties of like processes. Payment correction 
facilitates correction, for example, to the price or 
description of goods appearing in the authentication 
document, pursuant to notification of error received 
from selling company 2. Price settlement includes, 
for example, a response process executed by confirming 
detailed payment statements prepared by the Witness 
3, and a process wherein detailed payment statements 
prepared by buying company 1 itself are output. These 
processes are explained specifically below. 

Fig. 47 discloses, by way of illustration, the 
payment list screen appearing on the computer 5 
display. This payment list screen is displayed by 
pressing the payment list inquiry button 10b in the 
start menu, shown in Fig. 30. The payment list screen 
is generated by the Witness 3, and, by selecting the 
payor, the user can select, for example, "00 Foods 
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Company", "XX Ham Company", "ABC company", or any 
payor with whom the user conducts business. Also, 
when a payee is in the same way designated and a date 
specified, that date is displayed as the payment date 
5 in the payment list. 

The delivery date relating to the payment voucher, 
voucher number, store name, wholesale price, and 
discount rate, are displayed on this detailed list 
^2 screen. By specifying a payment voucher about which 

4i 10 more information is desired and pressing detail button 

in 

03 24a, the operator can shift to the detail screen 

represented in Fig. 48. 

Fig. 48 is an illustrative screen showing a 
H payment voucher requiring payment from payor "00 Foods 

^ 15 Company" to payee "XYZ Company" not later than August 

12, 1997. With this information displayed, the buying 
company 1 operator, or the selling company 2 operator, 
investigates product name, unit weight, quantity, unit 
price, total price, and like information, and, in case 
20 of any doubt, confirms each detail registered in the 
aforesaid receipts detail table 20, If, for example, 
the total amount differs from the amount determined 
based on the delivery receipt in the operator's 
possession, the operator checks each detail registered 
25 in the receipts detail table 20. 
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In this case, the operator would review the 
notarized, registered data residing in the receipts 
detail table 20. Specifically, the operator displays 
the aforesaid list screen shown in Fig. 45, by pushing 
5 the notarized data list button 10c from the start menu 
shown in Fig. 28. Further, the operator can display 
the notarized data detail screen and review payment 
li data. 

^ The detailed payment statement, which, by way of 

4" 10 illustration, can be prepared by the Witness 3, is 

produced with reference to the payment terms table 21. 
Due date, payment date, receiving account, and like 
information are for each company registered in the 
O payment terms table 21, by prior arrangement between 

15 buying company 1 and the Witness, or between selling 
company 2 and the Witness 3. Furthermore, each detail 
is assigned a detail number in the receipts detail 
table 20, and, for convenient review by either buying 
company 1 or selling company 2, a group table 22, 
20 grouping detail numbers, is prepared. 

Based on the aforesaid detailed payment statement, 
the Witness 3 next specifies the accounting department 
(i.e., a designated bank) receiving account and 
executes a funds transfer request (see Fig. 40(')). 
25 Fig. 50 describes the funds transfer process. 
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The Witness 3 prepares the detailed payment 
statement based on the data registered in the receipts 
detail table 20 and requests confirmation from buying 
company 1 (see Fig. 49(1)), Buying company 1 confirms 
5 the detailed payment statement sent to it by the 
Witness 3 and returns said detailed payment statement 
as a funds transfer request (see Fig. 49(2)). At this 
time, a delivery voucher index corresponding to the 
detailed payment statement in question is assigned to 

10 said detailed payment statement. 

The above-described funds transfer request is 
delivered to the Witness 3, via the notarization 
authority 7 (see Fig. 49 (3)), and transmitted to the 
bank, which is not represented in the instant figure. 

15 The funds transfer instruction sent by the Witness 3 
to the bank consists of the money amount, transferor, 
transferee, and the detail index. Having received the 
funds transfer instruction, the bank transfers funds 
to the appropriate account at selling company's 

20 transacting bank, utilizing a suitable banking system 
(e.g., the inter-bank exchange' system described 
above). The paying bank issues a payment notification 
to selling company 2 (see Fig. 49(4)). 

By performing processing as described above, 

25 buying company 1 and selling company 2 are not 
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required to hold several delivery vouchers and 
invoices and can execute efficient account settlement 
processing by sharing and using information provided 
by the Witness server 9 . 
5 Data transmitted (sent and received) among buying 

company 1, selling company 2, the notarization 
authority 7, and the Witness, are encoded and prepared 
as necessary to suit their respective transmission 
^ purposes. The illustrative data shown in Fig. 50 are 

==p 10 prepared for the purpose of substantive disclosure by 

Qj buying company 1 [A] to both selling company 2 [B] and 

" the Witness [W] . In this case, the data have been 

locked (secured) in advance with the selling company's 
O public access key (PKB), which is held by buying 

S 15 company 1, and the Witness' public access key (PKW). 

The data are further secured with a hash function and 
buying company's secrecy key (SHA), and then sent with 
a public key (PKN) appended thereto. This structure 
makes it impossible to release the aforesaid data 
20 without both selling company ''s secrecy key and the 
Witness' 2 secrecy key, and knowledge of the 
information is thus strictly limited to selling 
company 2 and the monitor 3 . 

Although the explanation of this illustrative 
25 embodiment does not touch upon the set-off process. 
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said process can be implemented as set: forth in the 
description of the previous illustrative embodiment. 

Third Alternate Embodiment: 
5 This portion of the specification describes the 

third alternate embodiment. 

This illustrative embodiment is directed 
particularly to account settlement by means of check 
or draft ( note ) , and can be implemented through 

10 systems based on both the above-described preferred 
and first alternate embodiments. Each contingency, 
viz., check and draft (note), is explained below. 

Fig. 51 describes, illustratively, account 
settlement in the case of checks. The administration 

15 center 50 shown in said figure comprises a 
notarization authority 51 and the Witness 52. The 
administration center adopts the Witness system 
described above and also undertakes management of 
bank-issued checks. Bank X represents the transacting 

20 bank for payor/buying company 1, and bank Y represents 
the transacting bank for receiver/selling company 2. 

First, buying company 2 (payor) issues a check. 
In the illustrative case, buying company 3 (payor), 
wishing to issue a check in payment for goods, must 

25 obtain a check by requesting that its transacting bank 
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X issue a check (see Fig. 51(1)). Bank X examines the 
applicant's eligibility and, when it is determined 
that a check ought to issue, the bank registers with 
the administration center 50 the issuance of a check 
to buying company 1 (see Fig. 51(2) and simultaneously 
authorizes buying company 1 to issue a check (see Fig. 



Having so obtained the check, buying company 1 
uses the check in payment for goods and tenders the 
check, on which are recorded the payee's name and the 
money amount, to selling company 2 (payee) (see Fig. 
51(4)). Selling company 2 takes the check it has 
received to the aforesaid transacting bank X and 
requests payment ( see Fig . 51(5)). 

Transacting bank X inquires of the administration 
system regarding the check presented to it and, in 
addition to confirming its validity, registers said 
check as paid by means of a payment notification (see 
Fig. 51(6)). Transacting bank X thereafter utilizes 
an inter-bank system to move funds to the specified 
account at the designated transacting bank (bank Y in 
this illustration), and bank Y then dispatches to 
selling company 2 notification of collection (see Fig. 



51(3)). 



51(7)). 



In 



this 



illustrative 



embodiment. 



the 



# 
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adminis-tra-fcion center is composed of a notarization 
authority and a Witness (system). The system 
undertakes check administration in the above-described 
network. Selling company 2 is the entity requesting 
5 that funds be transferred to bank Y. 

Processing of Drafts (Notes) 

.This portion of the specification explains the 
embodiment in the case of drafts (notes). 

10 Fig. 52 describes, illustratively, account 

settlement for drafts (notes). As in the check 
processing system, here, also, the administration 
center ( 53 ) is composed of a notarization authority 
54 and a Witness 55. The administration center adopts 

15 the above-described Witness system and also undertakes 
administration of bank-issued checks. Bank X 

represents the transacting bank for buying company 
1 /payor, and bank Y represents the transacting bank 
for selling company 2/payee. 

20 First, buying company 1 receives from transacting 

bank X authorization to issue a draft (note) (see Fig. 
52(1)). Next, buying company 2 registers issuance of 
a draft with the administration center 53, at the time 
buying company desires to issue said draft (see Fig. 

25 52(2)). The administration center 53 registers this 




56 

information and notifies buying company 1 of the 
registration number (see Fig, 52(3)). 

Buying company 1 adds to the registration number 
it has received a draw date, a drawee (payor), and a 
5 drawer (payee), and sends this information to selling 
company 2 (drawer) (see Fig. 52 (4)). Selling company 
2 presents this draft (note) to its transacting bank, 

% bank Y in this example, where it might request that 

bank Y purchase the draft (note) at a discount (see 

4z 10 Fig. 52(5)). 

Oj Bank Y confirms the information in said draft 

(note) with the administration center 53 and, further, 
l2 registers with the administration center.,-53 the fact 

H that bank Y itself is to be the drawer (payee) (see 

J3 15 Fig. 52(6)). Also, bank Y pays a discounted amount 

to selling company 2 (see Fig. 52(7)). 

Lastly, as the (payment) date approaches and the 
draft (note) is converted into currency, a settlement 
demand is tendered to the issuing bank (see Fig. 
20 52(8)), and bank X, which receives the settlement 
demand, uses the aforesaid inter-bank exchange system 
to move funds to the account at bank Y. Bank Y then 
provides notification of completion to the 
administration center 53 (see Fig. 52(9)). 
25 The administration center 53 for processes 
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executed in this illustrative embodiment comprises a 
notarization authority 54 and a Witness 55. The draft 
(note) administration flow " for this illustrative 
embodiment, also, is performed as described above. 
The Witness system can be used for this illustrative 
embodiment, as well. 

The following benefits are derived from the 
present invention. Through means of a single 
invention, the Witness stores (stores in memory/ holds 
in memory) and manages data relating, illustratively, 
to order vouchers and delivery vouchers, thus 
facilitating the preparation of accurate detailed 
payment statements. Additionally, because both Buyer 
and Seller can freely review detailed payment 
statements so prepared, it is not particularly 
necessary for Buyer or Seller to hold order vouchers 
and delivery vouchers. It is therefore unnecessary 
to perform the complicated task of arranging 
(organizing) various vouchers. 

In contrast to conventional settlement methods 
wherein Buyer prepares payment details while 
confirming order vouchers or delivery vouchers, it is 
no longer necessary for Seller to undertake the 
difficult task of confirming said payment details. 
Furthermore, system safety is ensured because 
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eligibility to participate in the system is verified, 
and because the exchange (transfer) of information is 
executed with encoded data. 



